OID4VP profile for the W3C Digital Credentials API #155
Conversation
|
Having discussed and thought about this more, I don't this proposal achieves the desired security properties namely allowing the wallet to authenticate the verifier before sending the response, please see here for more details, I've copied the same diagram below that I think captures the issue. 
On that basis I think we should consider revising the design somewhat to a simpler model which relies on authenticating the verifiers response encryption key as an additional layer of security above the existing mechanism the browser will provide which is to attest the origin of the verifier that sent the request. |
We had an extensive discussion on this issue at IIW and concluded to use signed requests in combination with |
|
@tlodderstedt, when you can, would you mind merging in the agreed to the suggestions? (just so it's a bit easier to review 😅). I'd like to do another round of review once those are merged. Thanks in advance!! 🙏 |
Co-authored-by: David Chadwick <[email protected]>
Co-authored-by: Marcos Cáceres <[email protected]> Co-authored-by: Sam Goto <[email protected]>
Co-authored-by: Joseph Heenan <[email protected]>
…ponse_mode Co-authored-by: Marcos Cáceres <[email protected]> Co-authored-by: Christian Bormann <[email protected]> Co-authored-by: Brian Campbell <[email protected]>
Sakurann
requested review from
samuelgoto,
marcoscaceres,
timcappalli,
c2bo,
awoie and
bc-pi
|
@marcoscaceres I am helping torsten with this PR. all the suggestions have been merged, please re-review |
|
|
||
| The `client_id` and `client_id_scheme` MUST be omitted in unsigned requests defined in (#unsigned_request). The Wallet determines the Client Identifier from the origin as asserted by the Web Platform and/or app platform. The transport of the request and origin from the Web Platform and/or app platform to the Wallet is platform-specific and is out of scope of this profile. | ||
|
|
||
| The value of the `response_mode` parameter MUST be `w3c_dc_api` when the response is neither signed nor encrypted and `w3c_dc_api.jwt` when the response is signed and/or encrypted as defined in (#jarm). |
There was a problem hiding this comment.
Going through the different issues and comments I could not find a definitive statement either way, but my understanding has been that response encryption is mandated either through the browser api (see WICG/digital-credentials#109 ) or by the underlying protocol (i.e. OpenID4VP in this case).
This sentence should therefore state that the response MUST be encrypted, unless the conclusion is that encryption will not be standardized / mandated on the protocol layer but the browser api layer.
|
|
||
| The `client_id` and `client_id_scheme` MUST be omitted in unsigned requests defined in (#unsigned_request). The Wallet determines the Client Identifier from the origin as asserted by the Web Platform and/or app platform. The transport of the request and origin from the Web Platform and/or app platform to the Wallet is platform-specific and is out of scope of this profile. | ||
|
|
||
| The value of the `response_mode` parameter MUST be `w3c_dc_api` when the response is neither signed nor encrypted and `w3c_dc_api.jwt` when the response is signed and/or encrypted as defined in (#jarm). |
There was a problem hiding this comment.
This sentence states the possibility for response signing. As this is a mechanism that directly effects interoperability, we should either remove the option or define the following details:
- What the purpose is of response signing, how do the threat models interact with response encryption and key/device authentication of the underlying credential formats
- How a signed response must be processed, what are the fallback options, how is support / requirements for it indicated.
- What are the mechanisms for response signing, is support for it optional / recommended / mandatory.
In the absence of a threat that requires response signing as a mitigating measure, I would recommend to remove the option for now and only add it when we know how and when it should be used.
Sakurann
dismissed
danielfett’s stale review
confirmed with Daniel before he went on vacation that he is ok with the PR
|
We also confirmed on today's working group call that Martijn is good with merging this PR as we have (or are about to) open issues to focus on his concerns and we'll discuss those (and some of the other open issues on the browser API) before we start the process for publishing the next implementer's draft. |
resolves #125